[レポート] Serverless Meetup Tokyo #2

渋谷マークシティのサイバーエージェント様の会場で行われた Serverless Meetup Tokyo #2 - connpass に参加してきましたのでレポートします。

スライドは公開され次第貼っていきます。

会場

会場は2スクリーンの部屋で定員が150名となっていましたがほぼ満席の状態でした。

開催側からビザとアルコールドリンクが振舞われました！

Opening: 2017年Serverless化していく世界の概況

吉田真吾 (セクションナイン)さま によるオープニングセッションです。

• Serverless Meetup の facebookのグループでのアンケート結果
  • サーバレスの開発ではどんなフレームワークを使っていますか？
    • serverless frameworkが1位
    • 続いてApex、lamveryなど
    • Microsoft Visual StudioやEclipseなどのIDEも増えている模様
  • サーバレスのどんな話を聞きたいですか？
    • 開発手法や技術選定といった意見が多かった
• 告知
  • 2017.04.26-29 US(オースティン)にてserverless Conferenceが開催されます!

Tune Up AWS Lambda

西谷圭介(AWS)さま によるAWS Lambdaのパフォーマンスに関するセッション。

• Lambdaの同時実行数
  • ストリームベース（Kinesis, DynamoDBStreams）はストリームサービスのシャード数と等しくなる
  • それ以外は、1sあたりのリクエスト数 * 処理時間 で計算できる
  • デフォルトで上限があるので足りなくなったら上限緩和申請をする
• Lambdaのライフサイクル
  • コンテナで実行されている
  • Dockerではない
  • 開始・終了・再利用・プロセスの凍結と再開の4つのフェーズからなる
  • 開始
    • コードがロードされる
    • VPC内の場合はENIの設定がされる
    • ハンドラ実行前の初期化コードが実行される（これをコールドスタートという）
  • 終了
  • 再利用
    • コードの変更がなく、前回の実行からあまり時間が経っていない場合はコールドスタートの状態が再利用される
    • 再利用が保証されているわけではない
  • プロセスの凍結と再開
• メモリ設定
  • 実際にはメモリに比例してCPU能力も増えるようになっている
  • 最小から少しづつ大きくしていって性能が変わらなくなる地点が最適値と言える
• バッチサイズ
  • ストリームベースの処理で有効な設定値
  • 一度に取得するレコードの最大数
  • 並列度を上げるには、シャードを増やして同時実行数を増やすか、バッチサイズを増やして内部的に並列度を上げる方法がある
• Lambdaの処理時間を早くするポイント
  • コールドスタートを早くする
    • 定常的にリクエストが発生している状態にする
    • リクエストがない場合はポーリングする（間隔は5分程度がおすすめ）
    • メモリ設定を増やすとコールドスタートの処理が早くなる
    • ランタイムを変える
      • JVMは起動は遅いが処理は速い傾向
      • 起動時間だけ見ると Java < C# < Python < Node
    • VPCは使わない
      • ENIのアタッチが遅い
      • RDBを使うのではなくDynamoDBStreamsを経由するのがおすすめ
    • パッケージサイズを小さくする
      • JavaはProGuardを使うことでサイズを小さくできる
    • Javaの場合だけ有効な手法
      • POJOではなくバイトストリームを使う
      • 匿名クラスをリプレースするようなJava8の機能を利用しない
  • 実行時間を短くする
    • メモリ設定を増やす
    • 各言語のベストプラクティスに従う
    • グローバルスコープを有効に使う（コールドスタートで初期化される）
      • 初期化コードをハンドラの外に置くことで、再利用される
  • 同時実行数を上げる
    • 並列度を上げるアーキテクチャにする
    • 同期実行ではなく非同期実行を利用する
    • 1ファンクションの処理時間を短くする

2017年のサーバレスアーキテクチャを考える - AppService/Event Hubs/Stream Analytics/Data Lake + カスタマー事例

前半は久森達郎(Microsoft) さま によるAzureでフロントWebサーバからデータ分析基盤までをサーバレスで構築する話。

• よくあるWebアプリケーションの構成のAzureアプローチ
  • Web
    • VMでコンテナ管理も結構辛いよね?
    • AzureはDockerコンテナを起動するPaasがあるよ（現在はプレビュー）
  • DB
    • DocumentDB（フルマネージドMongoDBと思っておけばOK）
    • Redis
  • データ分析
    • Event Hubs -> Functions/Stream Analytics -> Data Lake Store
      • Apache kafka + speark のようなイメージ
      • Data Lake AnalyticsはHadoopクラスタのようなもの?
• Functionsの活用例
  • ファイルをストリームにして処理したり
  • 画像加工したり
  • チャットボットしたり
• Functionsについて
  • ランタイムはNode, C#, PHP, Bash, 他色々
    • Bash環境にはなんとPerlの実行環境も入っており、Perlを使ったデモが行われました
  • Azureのアカウントがなくても試せる環境があります -> https://functions.azure.com/try

後半はAzureのユーザ事例として、東聡志さま によるサーバレスPush通知機能を作った事例紹介。

All your bugs are belong to ass — Azure + Perl でサーバレスなジョブシステムを作る

• Azureの機能を組み合わせてサーバレスでPush通知機能を作った
• なぜAzureを選んだ?
  • メインのシステムがオンプレ
  • 会社にAzureのEA（エンタープライズ?）契約があった
• アーキテクチャ
  • オンプレからEvent Hubsにペイロードを送信
  • Event HubsからQueue Storageにキューイング
  • Queue StorageからFunctionsを実行
  • FunctionsからNotification HubsへリクエストしてGCPやAPNsにPush送信
• ピーク時で3700件/分くらいさばいている
• まとめ
  • Notification HubsはPush送信の面倒なところをやってくれてモニタリングもしてくれるので良い
  • Functionsでの実装は簡単だった

サーバーレスAWS構成でセキュアなSPAを目指す - Cognito+API Gateway+Lambda+DynamoDB+KMS

加藤雅之(ハンズラボ)さま によるセキュアなSPAを作る事例紹介。

• SPAのベースとなるサイト
  • S3 + CloudFront
  • Route53
  • ACMで証明書取得
• APIの実装
  • API Gateway, CORSの有効化を忘れずに
  • バックエンドにLambda, 必要なRoleを設定
  • データストアはDynamoDB
  • API GatewayをデプロイをしてJavascriptのSDKを生成する
• セキュリティ
  • AWS WAFを使う
  • WAF -> CF -> API Gateway構成
  • Cognitoを認可に使う
    • UserPoolではなくFederated Identityを使った
    • LambdaでDeveloper Authentication Identity部分を実装した
    • 認証フローは複数あるが「拡張認証フロー」を使うのがおすすめ
  • トークンの有効期限に注意
    • STSのTokenの有効期限は1時間
      • CognitoのTokenで再発行する
    • CognitoのTokenは24時間
      • どうやって維持するかが課題だった
      • JWTを使った
      • Sigunetureで使うKeyはKMSで管理した
  • API GatewayのオーサライザーとしてLambdaを起動する
  • Cognitoのリソース管理設定でAWS内の認可されたユーザのリソースのみにアクセスする設定が可能

データ処理プラットフォーム in Serverless - AppEngine/Pub/Sub/Dataflow/BigQuery

福田潔(Google)さま によるGoogle Cloud Platfoamでのデータ処理について

• テーマは「Data + NoOps」
  • なんのためのData? 良いソフトウェアを作るため
  • なんのためのNoOps? 良いソフトウェアをより早く作り上げるため
• GCPのバックグラウンド
  • MapReduce後の歩みとして色々なソフトウェアやOSSが出てきた
  • Googleにはbillion（10億）ユーザを抱えるサービスが5つある
  • GCPは元々はGoogleが使うためのプラットフォームだったが、それらをサービスとして一般ユーザに提供している
• データ処理の流れ
  • 収集, PubSub, BigQueryStreaming, StackDriverLogging, AppEngine
  • 保存, CloudStorage, BigQueryStorage...
  • 処理, CloudDataFlow, DataProc（spreakのようなもの）
  • 分析, BigQuery, MachineLeaning
  • 可視化
• これらのサービスをどうやって組み合わせるのが良いのか
• BigQuery
  • フルマネージドDWH
  • SQLが使える
  • ペタバイトクラス
    • 1PBのスキャンがわずか130s!
  • 'select * from ~' はやっちゃダメ。処理したデータ量分の料金がかかる。
  • BigQueryの問題
    • 構造化されたデータしか扱えない
    • SQLで書くのが難しい処理がやりにくい
    • ストリーム的なデータの処理ができない
  • これらを解決するために生まれたのがCloudDataFlow
    • バッチにもストリームにも対応できる
    • プログラミングモデルとランタイムを提供
    • オートコンプリートの例が紹介されました

LT

メモってないのでスライドだけ!

Firebase+Railsのハイブリッドだからこそできた 2ヶ月で2つのチャットアプリを開発した話 - Google スライド

まとめ

普段はAWSをメインに仕事をしているのでGCPやAzureの話はとても興味深かったです。各Cloudベンダーとも共通しているのは、大量のストリームデータをイベント駆動（Function）でリアルタイムに処理するというところに注力している印象を受けました。またWebアプリケーションの分野では、マネジメントサービスを駆使して色々なシステムを構築する様子や苦労話が、開発者として単純に楽しそう!!と思いました。もちろん開発が楽しいだけではダメで、トータルコストや運用のしやすさなども考慮しなくてはならないのですが、まずは色々なことにチャレンジしてみようと思いました。